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Abstract 


This document lists the different mechanisms that enable applications 
using the Real-time Transport Protocol (RTP) and the RTP Control 
Protocol (RTCP) to keep their RTP Network Address Translator (NAT) 
mappings alive. It also makes a recommendation for a preferred 
mechanism. This document is not applicable to Interactive 
Connectivity Establishment (ICE) agents. 
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1. Introduction 


[RFC4787] and [RFC5382] describe Network Address Translator (NAT) 
behaviors and point out that two key aspects of NAT are mappings 
(a.k.a. bindings) and keeping them refreshed. This introduces a 
derived requirement for applications engaged in a multimedia session 
involving NAT traversal: they need to generate a minimum of flow 
activity in order to create NAT mappings and maintain them. 


When applied to applications using the Real-time Transport Protocol 
(RTP) [RFC3550], the RTP media stream packets themselves normally 
fulfill this requirement. However, there exist some cases where RTP 
does not generate the minimum required flow activity. 


The examples are: 


o In some RTP usages, such as the Session Initiation Protocol (SIP) 
[RFC3261], agents can negotiate a unidirectional media stream by 
using the Session Description Protocol (SDP) [RFC4566] "recvonly" 
attribute on one agent and "sendonly" on the peer, as defined in 
[RFC3264]. [RFC3264] directs implementations not to transmit 
media on the receiving agent. If the agent receiving the media is 
located on the private side of a NAT, it will never receive RTP 
packets from the public peer if the NAT mapping has not been 
created. 
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o Similarly, a bidirectional media stream can be "put on hold". 
This is accomplished by using the SDP "sendonly" or "inactive" 
attributes. Again, [RFC3264] directs implementations to cease 


transmission of media in these cases. However, doing so may cause 
NAT bindings to time out, and media won’t be able to come off 
hold. 


o Some RTP payload formats, such as the payload format for text 
conversation [RFC4103], may send packets so infrequently that the 
interval exceeds the NAT binding timeouts. 


To solve these problems, an agent therefore needs to periodically 
send keepalive data within the outgoing RIP session of an RTP media 
stream regardless of whether the media stream is currently inactive, 
sendonly, recvonly, or sendrecv, and regardless of the presence or 
value of the bandwidth attribute. 


It is important to note that NAT traversal constraints also usually 
require that the agents use Symmetric RIP / RIP Control Protocol 
(RTCP) [RFC4961] in addition to RTP keepalive. 


This document first states the requirements that must be supported to 
perform RTP keepalives (Section 3). In a second step, the document 
reports the different mechanisms to overcome this problem 

(Section 4). Section 5 finally states the recommended solution for 
RTP keepalive. Section 6 discusses some media format exceptions. 
Section 7 adds details about timing and transport considerations. 
Section 8 documents how to maintain NAT bindings for RTCP. 


This document is not applicable to Interactive Connectivity 
Establishment (ICE) [RFC5245] agents. Indeed, the ICE protocol, 
together with Session Traversal Utilities for NAT (STUN) [RFC5389] 
and Traversal Using Relays around NAT (TURN) [RFC5766], solves the 
overall Network Address Translator (NAT) traversal mechanism of media 
streams. In the context of RTP media streams, some agents may not 
require all ICE functionalities and may only need a keepalive 
mechanism. This document thus applies to such agents, and does not 


i 


apply to agents implementing ICE. 


Note that if a given media uses a codec that already integrates a 
keepalive mechanism, no additional keepalive mechanism is required at 
the RTP level. 


As mentioned in Section 3.5 of [RFC5405], "It is important to note 
that keepalive messages are NOT RECOMMENDED for general use -- they 
are unnecessary for many applications and can consume significant 
amounts of system and network resources". 
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2. Terminology 


In this document, the key words "MUST", "MUST NOT", "REQUIRED", 
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 
and "OPTIONAL" are to be interpreted as described in RFC 2119 
[RFC2119]. 


3. Requirements 


This section outlines the key requirements that need to be satisfied 
in order to provide RTP media keepalive. 


REQ-1 Some data is sent periodically within the outgoing RIP session 
for the whole duration of the RTP media stream. 


REQ-2 Any type of transport (e.g., UDP, TCP) MUST be supported. 
REQ-3 Any media type (e.g., audio, video, text) MUST be supported. 
REQ-4 Any media format (e.g., G.711, H.263) MUST be supported. 
REQ-5 Session signaling protocols SHOULD NOT be impacted. 
REQ-6 Impacts on existing software SHOULD be minimized. 
REQ-7 The remote peer SHOULD NOT be impacted. 
REQ-8 The support for RIP keepalive SHOULD be described in the SDP. 
REQ-9 The solution SHOULD cover the integration with RTCP. 

4. List of Alternatives for Performing RIP Keepalive 


This section lists, in no particular order, some alternatives that 
can be used to perform a keepalive message within RTP media streams. 


4.1. Empty (0-Byte) Transport Packet 


The application sends an empty transport packet (e.g., UDP packet, 
Datagram Congestion Control Protocol (DCCP) packet). 


Con: 


o This alternative is specific to each transport protocol. 
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4.2. RIP Packet with Comfort Noise Payload 


The application sends an RTP packet with a comfort noise payload 
[RFC3389]. 


Cons: 

o This alternative is limited to audio formats only. 

o Comfort noise needs to be supported by the remote peer. 

o Comfort noise needs to be signaled in SDP offer/answer. 

o The peer is likely to render comfort noise at the other side, so 
the content of the payload (the noise level) needs to be carefully 
chosen. 

4.3. RICP Packets Multiplexed with RTP Packets 

The application sends RTCP packets in the RTP media path itself 

(i.e., the same tuples for both RTP and RTCP packets) [RFC5761]. 

RTCP packets therefore keep the NAT mappings open as long as the 

requirements for parameter selection are fulfilled as discussed in 


Section 8. 


Note: The "on hold" procedures of [RFC3264] do not impact RTCP 
transmissions. 


Cons: 
o Multiplexing RTP and RTCP must be supported by the remote peer. 


o Some RTCP monitoring tools expect that RTCP packets are not 
multiplexed. 


o RTCP must be configured so that the Tmin value [RFC3550] is less 
than or equal to the Tr interval. 
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4.4. STUN Indication Packet 


The application sends a STUN [RFC5389] Binding Indication packet as 
specified in ICE [RFC5245]. 


Thanks to the RTP validity check, STUN packets will be ignored by the 
RTP stack. 


Con: 
o The sending agent needs to support STUN. 
4.5. RTP Packet with Incorrect Version Number 


The application sends an RTP packet with a version number set to zero 
(i.e., an incorrect version number). 


Based on the RTP specification [RFC3550], the peer should perform a 
header validity check and therefore ignore these types of packets. 


Cons: 


o Only four version numbers are possible. Using one of them for RTP 
keepalive would be wasteful. 


o [RFC4566] and [RFC3264] mandate that media with inactive and 
recvonly attributes not be sent; however, this is mitigated, as no 
real media is sent with this mechanism. 


4.6. RIP Packet with Unknown Payload Type 


The application sends an RTP packet of 0 length with a dynamic 
payload type that has not been negotiated by the peers (e.g., not 
negotiated within the SDP offer/answer, and thus not mapped to any 
media format). 


The sequence number is incremented by one for each packet, as it is 
sent within the same RTP session as the actual media. The timestamp 
contains the same value that a media packet would have at this time. 
The marker bit is not significant for the keepalive packets and is 
thus set to zero. 


The synchronization source (SSRC) is the same as for the media for 
which keepalive is sent. 


Normally, the peer will ignore this packet, as RTP [RFC3550] states 
that "a receiver MUST ignore packets with payload types that it does 
not understand". 
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Cons: 


o [RFC4566] and [RFC3264] mandate that media with inactive and 
recvonly attributes not be sent; however, this is mitigated, as no 
real media is sent with this mechanism. 


o [RFC3550] does not preclude examination of received packets by the 
peer in an attempt to determine if it is under attack. 


o The statement "a receiver MUST ignore packets with payload types 
that it does not understand" of [RFC3550] is not always observed 
in real life. 


o There is no RICP reporting for the keepalive packets, as [RFC3550] 
mandates that RTP packets with payload types that the receiver 
does not understand be ignored. 


o Some RTP payload formats do not handle gaps in RTP sequence number 
well. 


5. Recommended Solution for Keepalive Mechanism 
The RECOMMENDED mechanism is that discussed in "RTCP Packets 
Multiplexed with RTP Packets" (Section 4.3). This mechanism is 
desirable because it reduces the number of ports when RTP and RTCP 
are used. It also has the advantage of taking into account RTCP 


aspects, which is not the case with other mechanisms. 


Other mechanisms (Sections 4.1, 4.2, 4.4, 4.5, and 4.6) are NOT 
RECOMMENDED. 


6. Media Format Exceptions 
When a given media format does not allow the keepalive solution 
recommended in Section 5, an alternative mechanism SHOULD be defined 
in the payload format specification for this media format. 

7. Timing and Transport Considerations 
An application supporting this specification MUST transmit either 
keepalive packets or media packets at least once every Tr seconds 
during the whole duration of the media session. 


Tr has different value according to the transport protocol. 


For UDP, the minimum RECOMMENDED Tr value is 15 seconds, and Tr 
SHOULD be configurable to larger values. 
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For TCP, the recommended Tr value is 7200 seconds. 


When using the "RTCP packets multiplexed with RTP packets" solution 
(Section 4.3) for keepalive, Tr MUST comply with the RTCP timing 
rules of [RFC3550]. 


Keepalive packets within a particular RTP session MUST use the tuple 
(source IP address, source TCP/UDP port, target IP address, target 
TCP/UDP port) of the regular RTP packets. 


The agent SHOULD only send RTP keepalive when it does not send 
regular RTP packets. 


8. RTCP Flow Keepalive 


RTCP packets are sent periodically and can thus normally keep the NAT 
mappings open as long as they are sent frequently enough. There are 
two conditions for that. First, RTCP needs to be used 
bidirectionally and in a symmetric fashion, as described in 
[RFC4961]. Secondly, RTCP needs to be sent frequently enough. 
However, there are certain configurations that can break this latter 
assumption. 


There are two factors that need to be considered to ensure that RTCP 
is sent frequently enough. First, the RTCP bandwidth needs to be 
sufficiently large so that transmission will occur more frequently 
than the longest acceptable packet transmission interval (Tr). The 
worst-case RTCP interval (Twc) can be calculated using this formula 
by inserting the max value of the following parameters: 


o Maximum RTCP packet size (avg_rtcp_size_max) 
o Maximum number of participants (members_max) 
o RTCP receiver bandwidth (rtcp_bw) 


The RTCP bandwidth value to use here is for a worst case, which will 
be the receiver proportion when all members except one are not 
senders. This can be approximated to be all members. Thus, for 
sessions where RR and RS values [RFC3556] are used, then rtcp_bw 
shall be set to RR. For sessions where the [RFC3550]-defined 
proportions of RTCP bandwidth are used (i.e., 1/4 of the bandwidth 
for senders and 3/4 of the bandwidth for receivers), then rtcp_bw 
will be 5% of 3/4 of the AS value [RFC4566] in bits per second. 


Twc = 1.5 / 1.21828 * members_max * rtcp_bw / avg_rtcp_size_max * 8 
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The second factor is the minimum RTCP interval Tmin defined in 
[RFC3550]. Its base value is 5 seconds, but it might also be scaled 
to 360 divided by the session bandwidth in kbps. The Extended RTP 
Profile for Real-time Transport Control Protocol (RTCP)-Based 
Feedback (RTP/AVPF) [RFC4585] also allows for the setting of a 
trr-int parameter, which is a minimal RTCP interval for regular RTCP 
packets. It is also used as the Tmin value in the regular Td 
calculation. An analysis of the algorithm shows that the longest 
possible regular RTCP interval is: 


RTCP_int max = trr-int * 1.5 + Td * 1.5 / 1.21828 

And as long as there is sufficient bandwidth according to criteria 1 
below, then the algorithm can be simplified by setting Td = trr-int, 
giving 

RTCP_int_max = trr-int * (1.5 + 1.5 / 1.21828) = 2.73123 * trr-int 


Thus, the requirements for the RTCP parameters are as follows for 
functioning keepalive: 


1. Ensure that sufficient RICP bandwidth is provided by calculating 
Twc, and ensure that the resulting value is less than or equal 
CONTES: 


2.2 If AVP or SAVP [RFC3711] is used, the Tmin value can’t be greater 
than Tr divided by 1.5 / (e-3/2). 


34 If AVPF or SAVPF [RFC5124] is to be used, trr-min must not be set 
to a value greater than Tr / 3. 


9. Security Considerations 


The RIP keepalive packets are sent on the same path as regular RTP 
media packets and may be perceived as an attack by a peer. However, 
[RFC3550] mandates that a peer "ignore packets with payload types 
that it does not understand". A peer that does not understand the 
keepalive message will thus appropriately drop the received packets. 
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